All rights reserved. No part of this publication may be reproduced in any form or by any means, without prior written permission by Oberon microsystems. The only exception is the free electronic distribution of the educational version of Oberon/F (see the accompanying copyright notice for details).
Oberon/F module interfaces and their descriptions in particular may not be used in other works without written permission.
Oberon microsystems, Inc.
Solothurnerstr. 45
CH-4053 Basel
Switzerland
This text has been produced with Oberon/F. Printed on acid-free paper.
Oberon is a trademark of ETH Z
rich, Switzerland.
Oberon/F, Oberon/L, and "Drag & Pick" are trademarks of Oberon microsystems, Inc.
All other trademarks and registered trademarks belong to their respective owners.
Preface
Oberon was started in 1985 as a research project at the Eidgen
ssische Technische Hochschule Z
rich* (ETH). It was an attempt to distill the essence of earlier operating systems research of the Xerox Palo Alto Research Center into a comprehensive, but still comprehensible, workstation operating system. The comprehensibility of any design is tied to its simplicity and to its regularity. Both could only be achieved by starting from scratch, i.e. by designing the new operating system from the ground up. The researchers Niklaus Wirth and J
rg Gutknecht even went so far as to design their own user interface and window system for that purpose. As a result, the new operating system became very small and efficient, working well in only 2 MB of RAM and 10 MB of disk space.
Another reason for the small size of this operating system was its extensibility: instead of integrating all desirable features into one monolithic software colossus, the less frequently used software components could be implemented as extensions of the core system. Such components were only loaded when they were actually needed, and they could be shared by several applications. In fact, there was no clear-cut boundary between the "operating system" and an "application", because applications could be tightly integrated with the operating system, and with each other.
The operating system was also tightly integrated in another sense, namely with the programming language in which it was implemented. Procedures in this language could be called directly from the operating system's command interpreter, and the operating system in turn relied heavily on the safety features of this programming language and its implementation (compiler and run-time system). In fact, both the operating system and the programming language were developed hand in hand. To stress this integrated, "wholistic" approach, both the operating system and the language eventually were christened with the same name: Oberon.
In 1987, the first version of Oberon became operational. At ETH's Institut f
r Computersysteme it soon began to replace other operating systems. It was used for software development, for everyday work such as writing letters and papers, up to the development of computer boards and circuits, including the necessary CAD software.
Based on this encouraging experience, the system and the language were further developed, and experimental variations of both were designed and tried out. At the same time, the original work was documented in several books, and ports to various workstations were undertaken.
The positive impression that Oberon made, due to its simplicity, efficiency, high level of integration, and to its productivity in general, was nevertheless overshadowed by its limited appeal to a wider audience: a new operating system without support for legacy systems and with a non-standard textual user interface would never be more than an interesting experiment, relegated to research environments.
The only way to make some of the results of the ETH Oberon project available to a larger public, was to design an Oberon system which was neither a complete operating system nor had its own user interface. Still it had to retain most advantages of the original Oberon system, because yet another traditional language / library product would offer too little benefit either.
* ETH is the Swiss Federal Institute of Technology
Thus Oberon microsystems, Inc. was formed as a spin-off of ETH, with the goal to consolidate the experience gained from various ETH system and language versions into a commercial-grade product, which would fit into the prevailing computing environments. Oberon microsystems developed the Oberon framework, or Oberon/F in short, starting in 1992. The scope of this product lies between an operating system and an application. It can be extended at run-time like an operating system, but runs on top of industry standard operating systems like normal applications do. It is an integrated development environment, a visual designer, a cross-platform class library, a compound document facility, a word processor, as well as the run-time environment of Oberon applications. Rather than providing its own user interface, Oberon/F adapts to the user interface of the host platform on which it runs.
While Oberon/F adopted many concepts and ideas of the various ETH Oberon systems, it is basically a new design, optimized for conformance with industry standard operating systems and graphical user interfaces.
This book is the standard documentation for Oberon/F; it consists of three parts. It requires knowledge of the Oberon programming language.
Part I: Introduction and Overview
In the introduction, general concepts like application frameworks, compound documents, and component frameworks are introduced. In the overview, more specific concepts are described, as they have been appliedto the design of Oberon/F.
Part II: Tutorial
Three classes of Oberon/F programmers can be distinguished:
- Command programmers implement specialized uses of existing software subsystems. Command programming can also involve menu and forms design (i.e. plugging together existing components). The scope of commands can range from simple scripts to advanced algorithms like spelling checkers.
- View programmers implement new subsystems, including all necessary data types for the representation and visual presentation of their data, as well as for the interaction with these data.
- Container programmers implement complex view subsystems, which provide views that can contain other views. Such views typically support in-place editing of their embedded views.
There is one chapter devoted to command programming and one chapter devoted to view programming. Command programming is demonstrated by a series of short example programs, e.g. demonstrating how program code can be associated with the controls of a dialog box.
View programming is demonstrated by a sequence of programs, starting with a minimal view implementation of a "Hello World" program. This program is refined again and again, until all major concepts concerning a view implementation have been presented.
Container programming is the most demanding form of view programming. It will be described in another book about advanced Oberon/F programming topics. If you want to start container programming immediately, please consult the on-line documentation of Oberon/F. It contains the source code of the forms subsystem as an example of a container implementation.
Part III: Reference
The reference part of this book contains an overview over the Oberon/F architecture, followed by the descriptions of the public modules of the Oberon/F core and of the standard Oberon/F subsystem modules. Each module description consists of three parts. First, the interface of a module (its definition) is listed, to give an overview and to serve as a quick reference. Then the abstractions and services provided by this module are explained. Finally, all constants, types, variables, and procedures of this module are commented individually. Formal descriptions of preconditions, postconditions, and invariants are given where they appear helpful. The module references are intentionally kept complete but short, examples can be found in the tutorial section and in the documentation "Oberon/F, Framework, Quick Start and Quick Reference".
Contents
Preface
Contents
Part I Introduction and Overview
1 Introduction
1.1 Oberon: a Language and More
1.2 From Applications to Application Frameworks
1.3 Compound Documents
1.4 From Application Frameworks to Component Frameworks
1.5 Garbage Collection
1.6 The Architect's Tools of the Trade
1.7 From White-Box Frameworks towards Black-Box Frameworks
2 Overview 19
2.1 Module and Type Hierarchies 19
2.2 Device Drivers: Carriers, Riders, Mappers, and Directories 25
2.3 User Interaction: Models, Views, and Controllers 27
(.txt)